yaboot
for a while.
But procrastinating sometimes helps, and when I should have been writing
and studying, on December I gave GRUB a new try on my laptop to see if a few
important changes to memory allocation would have changed anything. And it did!
So after fighting quite a few problems, I was able to
report partial success
to grub-devel
.
Again, getting GRUB installed correctly was a bit challenging and needed
some hackery, due to incorrectly generated device.map
, and the
linux module mysteriously not getting loaded. Luckily, Michel D nzer found out
that this was due to a bug in sort ordering in the HFS module, which broke
the lookup of files with underscores like _linux.mod
, and for
which he posted a possible fix by taking Linux's table of character
ordering, which is a blob of hex values.
GRUB developers didn't seem too happy about applying the patch:
they argument that a blob like that should be well documented or written
in some other more readable way, and there's a possible problem with the mix
of Linux GPLv2 and GRUB GPLv3+ codebases, if a table of data like what Michel
posted is actually copyrightable. The discussion ended up dying and nothing
was done... until Pavel Roskin
picked it up
weeks later and posted a new patch, based on hfsutils
GPLv2+
code, which addressed these issues. The new patch seems to have a few issues,
which makes it fail as before, but hopefully it'll be fixed soon.
Additionally, I wasn't able to boot using UUIDs as the search commands
fails to detect the correct boot device on my system (but not on Michel's), so
I had to disable that in /etc/default/grub
.
To workaround the linux module loading bug while the patch is fixed,
I just added this ugly hack to /etc/grub.d/09_local_prelinux
:
#! /bin/sh -e # Work-around for bugs in the hfs module which makes the load of # linux.mod fail. cat << EOF insmod (hd,3)/usr/lib/grub/powerpc-ieee1275/_linux.mod insmod linux EOFThis is enough to get the
initrd
and linux
commands available. However, update-grub will still add search
commands to your menu entries even if you disabled UUID support; I can't
understand why, but I know it breaks on my PowerBook due to some OF rarety.
Just removing the line from the menu entry will leave me with a working
config that boots without any manual editing at GRUB prompt.
The latest GRUB snapshot in Debian fixes the device.map issue, but adds
one last
issue:
update-grub will fail due to some gfxterm detection code, a workaround is
to replace an exit 1
with exit 0
when this happens
in /etc/grub.d/00_header
.
On the weird architectures front, it's worth noting that this month
Dave Miller popped up on the list and started posting patches to fix the rotten
SPARC port, and I think it's safe to assume that it'll be on an usable state
really soon. Impressive!
gvfs
.
The Debian GNOME team is obviously not ignoring this fact and started to
work very hard on updating GNOME for squeeze as soon as the
lenny freeze was over.
First, the new versions of GLib and GTK+ were uploaded to unstable, and
managed to transition to testing very easily. The rest of GNOME 2.24 bits,
which had been patiently waiting on experimental for months, has been uploaded
with care not to disrupt any of the many transitions the Debian release team
is currently dealing with. You can have a quick glance at how things are going
in our 2.24 status page,
but the summary is that most of GNOME 2.24 is in unstable, with a few notable
exceptions which are held back by ongoing testing transitions. Namedly,
evolution-data-server
is trying to trickle into testing, which
is in turn holding the final bits: gnome-panel, nautilus and related packages,
but we think this will be over soon.
As soon as GNOME 2.24 is safe in squeeze, we'll immediately
turn our focus to the new GNOME 2.26 release. Our initial plan is to
package
the trivial bits and leaf packages which can't break stuff for unstable, and
herd the more complex modules via experimental, to avoid breaking unstable
at all. There are some exceptions; we plan to keep gnome-session
2.22 in unstable/testing until 2.26.1 is released to avoid getting a
broken session saving
in Debian.
People might wonder why we insist on hitting what would seem a dead horse
by first dealing with 2.24 and not 2.26 directly. The main reason is that these
packages had been ready for a long time, and were in good shape to transition
to testing quickly and with little pain. Preparing 2.26 directly would mean
throwing away a lot of hours of packaging and polishing effort, and it's not
like we're releasing squeeze any time soon anyway.
Enjoy the hopefully not too bumpy road to 2.26!
Frago and I, after last year's cal ot war
natura.oskuro.net
, the home server which still serves this
blog, has been suffering hardware problems for some weeks. Apparently the
hard drive is failing intermittently, so every now the kernel starts spewing
out noisy errors about its main disk dying. If I notice this quickly, it can
be rebooted and that normally fixes it for a few more days. But if I don't,
it'll end up giving nasty bus errors
which will make remote
logins a challenge. Most processes still work, but the filesystem appears
to be gone. It's easy to know what's going on if you visit the blog's url
and get some 404
, and in that case I can only phone my father
and tell him to press the reset button (I've tried sysrqd, but I need to
open the port in the router and haven't had chance to do that yet).
So it was time to do something about it, and the other day I installed a
dirty 40GB drive on the second IDE controller, in case I could find the time
to do somethng about it. Being with an endless pharyngitis that doesn't seem
to get cured entirely, I've had some time today to look at it. This evening,
I was about to transfer all the system to the new disk (it's half
the size as the broken one, and probably slower, but it hopefully has
no bad sectors), but I decided to upgrade the system first.
natura
was first installed in late 1997 or at the beginning
of 1998, using the Debian bo install media on a Pentium 150MHz, and
has gone through seven dist-upgrades which, as far as I can remember, have
always worked out without major problems.
The upgrade to lenny hasn't been an exception. The server has
gradually lost many of the services it once hosted, so there aren't too many
services to take care of anymore. All the mail services I setup for my father
ended up being deprecated as they started to get used to Hotmail, GMail and
so on, and the frequent hardware crashes made me switch them to the Linksys
based DHCP server. In the end, the problems I saw after the upgrade were
very similar to what I faced when I
upgraded to etch:
apache2
restored the 000-default
symlink in
the sites-enabled
dir, which resulted in my website showing
the classic It works message for a while.coding=utf-8
line to the
beginning of my config.py
to get it working.dhcp3-server
apparently restored its init scripts and got
started again. This time, it got removed.apt-show-versions
to find out what didn't match my
package sources. I found I had every single version of cpp, gcc and g++ from
2.95 to 4.3, and a myriad of obsolete libs. But there were also real gems:
Spaniards will remember queso because it was written by Jordi Murg and became a classic tool to find out what OS was running on a remote host. update was apparently needed to flush your filesystems prior to Linux 2.2.8, and defrag is obvious, although leaves me wondering why it was needed at the time. With the upgrade done successfully, next step is trying to get the system transfered to the spare hard drive. For this, I first partitioned it creating a primary partition using up more or less half of the available space, and setup a LVM volume, leaving some free PE's in the volume group just in case I want to do snapshots in the future, and formatted it using ext3. I then transfered the system to the new disk and now face the boot challenge. I haven't created a boot partition and that should be a double problem: the BIOS is buggy and will only boot from the first 1024 cylinders, and my root is on LVM and GRUB legacy might not like it (but I'm not sure). However, I've become a big fan of GRUB2, and know I will be able to boot no matter what my BIOS thinks of my disks and regardless the complex root partition setup I throw at it. The plan is to install GRUB onto the new drive's MBR, and set it up using thedefrag 0.73pjm1-7 installed: No available version in archive figlet 2.2.1-3 installed: No available version in archive ipmasqadm 0.4.2-2 installed: No available version in archive isapnptools 1.26-5 installed: No available version in archive ms-sys 2.1.0-1 installed: No available version in archive queso 0.980922b-3 installed: No available version in archive update 2.11-4 installed: No available version in archive
ata
module, which should
allow to ignore what the BIOS says, and read beyond cylinder 1024 or even boot
from CD-ROM. However, this isn't a setup I haven't tried before, and a single
failure will result in me taking a train to fix it on-site.
So, GRUB experts out there, any suggestions? Of course, for now I guess I
can install GRUB in the current drive's MBR and make it boot the old kernel
using the new system as root, but that's dirty and would just postpone the
problem.
Barcelona-Istanbul
means
the third chapter of the unplanned saga Chistmas in Islam . Two years ago
I started 2007 visiting
Tunisia,
and last year we enjoyed a 10 day trip around the South of
Morocco,
which was absolutely fantastic (and I've still haven't blogged about).
This year I'll be discovering Istanbul, Cappadocia and other parts of
Turkey with Maria. The idea is to try to avoid visiting too many places
in a rush, and follow the good advice of our Moroccan friends, La prisa
mata, amigo . We have plenty of days to explore Turkey's secrets, but
I want to be able to enjoy them, and avoid being in a constant hurry.
As always, I'll be glad to get suggestions on must not miss places or
things, and advice on how to move around, where to stay, what to do or what
not to do is extremely welcome. I'm totally looking forward to this,
after I missed this years's GUADEC!
Uno, que no pare ninguno!
Next.